{} syntax

[Mark Rogers]

While I think about it, can I suggest that assuming we retain the
current use of curly braces {} (which I assume and hope we will), can we
define that there must be no whitespace immediately after the opening
brace or before the closing brace? Ie:
{$var} - valid
{ $var } - invalid

The reason I suggest this is that scripts and styles within the template
would no longer need escaping:
function test()
{
{if $foo == $bar}alert('foo = bar');{else}alert('foo != bar'){/if}
}
or
.bg {
background-color: {$bgcolor};
color: {$fgcolor};
}

Actually it's only after the opening brace that really matters, it's not
ambiguous to allow whitespace before the closing brace.

I know that the delimiter can be changed, but using {} is easy to read
and consistent with existing templates.

--
Mark Rogers // More Solutions Ltd (Peterborough Office) // 0845 45 89 555
Registered in England (0456 0902) at 13 Clarke Rd, Milton Keynes, MK1 1LG

[Monte Ohrt]

Alpha already exhibits this behavior, so yes!

[Michael Hurni]

FYI only...

At my mind.. {rdelim} / {ldelim} are to long to write..
I modify my smarty compiler to replace {{ by {ldelim},  }} by {rdelim}  before the parsing..
So I write now

.bg {{
      background-color: {$bgcolor};
      color: {$fgcolor};
 }}

Michael

2008/10/24 Monte Ohrt <mo...@ohrt.com>

[Mark Rogers]

Michael Hurni wrote:
> FYI only...
>
> At my mind.. {rdelim} / {ldelim} are to long to write..
> I modify my smarty compiler to replace {{ by {ldelim}, }} by
> {rdelim} before the parsing..
> So I write now
>
> .bg {{
> background-color: {$bgcolor};
> color: {$fgcolor};
> }}
>

FYI also, I wrote a {script} pre-processor which replaced any { which
was followed by whitespace with {ldelim}, and any } preceded by
whitespace by {rdelim}, so that the code examples I wrote previously
would work as written. I have since realised that (a) I rarely need
{literal} any more now that I have {script}, and (b) I don't have to
"think" inside the {script}..{/script} block about what works and what
doesn't, it just works "naturally". Which is why I think having that
functionality everywhere by default makes life much easier.

[Michael Hurni]

It's a nice way too..
I will use yours

in future smarty3 ?

Michael

2008/10/24 Mark Rogers <ma...@quarella.co.uk>

[Monte Ohrt]

Smarty 3 does not parse delimiters next to white space. So:

.bg {
background-color: {$bgcolor};
color: {$fgcolor};
}

Will work, no errors. $bgcolor and $fgcolor will get parsed, the other
delims are ignored.

Michael Hurni wrote:
> It's a nice way too..
> I will use yours
>
> in future smarty3 ?
>
> Michael
>
>

> 2008/10/24 Mark Rogers <ma...@quarella.co.uk <mailto:ma...@quarella.co.uk>>

[Frank Schummertz]

Monte Ohrt schrieb:

> Alpha already exhibits this behavior, so yes!

Does this mean that whitespaces after left delimiters are invalid in
3.0? If so this will surely break a lot of existing templates.

Frank

[Giovanni Giacobbi]

My 2 cents: I don't like the whitespace solution, because it may cause unexpected side effects. Think about a Javascript developer trying to debug his javascript code included inside a bigger project using {include}: The Javascript developer is unaware that his script will be piped thru smarty, so it may happen that:

function x(var i) { return i + 1; }

works, but:

function x(var i) {return i + 1;}

does not. They are both perfectly valid javascript. What is my point? My point is that if Smarty parses {rdelim} and {ldelim} as it does now (2.x) the Javascript code will always give error, not only if the unaware javascript developer doesn't put the whitespace around braces. This will eventually save time to developers.

[Monte Ohrt]

It's the lesser of two evils. Either this throws an error (smarty 2):

function foo() {  return 1;   }   // smarty 2 tries to interpret as template tags

or this throws an error (smarty 3):

function foo() {return 1}   // smarty 3 tries to interpret as template tags

I think the latter is going to happen less often and more friendly to template designers. You will just have to follow a js/css formatting convention for Smarty3 templates, or wrap the whole thing in {literal} tags.

[Cameron Perry]

What if we were to to do the unthinkable and change the default smarty delimiters? I've used {{ }} and <{ }> with success in the past (I personally prefer <{ }>) - I've always been suspicious of using just { } because of JS, and because one of my apps allows admins to use some smarty code in text regions, I wanted to avoid the potential conflict in the off chance any of them ever used a single curly bracket in the page content.

~Cameron

[Ldath]

On 24 Paź, 16:18, Monte Ohrt <mo...@ohrt.com> wrote:
> Smarty 3 does not parse delimiters next to white space. So:
>
> .bg {
>       background-color: {$bgcolor};
>       color: {$fgcolor};
>
> }
>
> Will work, no errors. $bgcolor and $fgcolor will get parsed, the other
> delims are ignored.
>

And this is very good information. If somebody like 2.0 way can use
{literal}{/literal}. I prefer this new feature

[azrad]

Is it possible to have something like this:

1. for conditional statement, we use

<% if ($has_logged_in) %>
User already logged in.
<% endif %>

2. for print variable, we use

Hello <%= $first_name %>


Thanks and best regards,

On Oct 28, 3:05 pm, Cameron Perry <came...@filled.us> wrote:
> What if we were to to do the unthinkable and change the default smarty  
> delimiters? I've used {{ }} and <{ }> with success in the past (I  
> personally prefer <{ }>) - I've always been suspicious of using just  
> { } because of JS, and because one of my apps allows admins to use  
> some smarty code in text regions, I wanted to avoid the potential  
> conflict in the off chance any of them ever used a single curly  
> bracket in the page content.
>
> ~Cameron
>
> On Oct 24, 2008, at 8:14 PM, Monte Ohrt wrote:
>
> > It's the lesser of two evils. Either this throws an error (smarty 2):
>
> > function foo() {  return 1;   }   // smarty 2 tries to interpret as  
> > template tags
>
> > or this throws an error (smarty 3):
>
> > function foo() {return 1}   // smarty 3 tries to interpret as  
> > template tags
>
> > I think the latter is going to happen less often and more friendly  
> > to template designers. You will just have to follow a js/css  
> > formatting convention for Smarty3 templates, or wrap the whole thing  
> > in {literal} tags.
>
> > On Oct 24, 2008, at 3:21 PM, Giovanni Giacobbi wrote:
>

> >> On Fri, Oct 24, 2008 at 7:44 PM, Frank Schummertz <frank.schumme...@landseer-stuttgart.de

[Ted]

I would prefer both ways. The new one and for compatibility reasons
the old one.

Regards,
Thorsten

[Frank]

Perhaps an old topic, but why not make

{css}

and

{script style='text/javascript'}

tags ?

easy for designers and readability is also fine.

[kabot]

Frank wrote:
> Perhaps an old topic, but why not make
>
> {css}
>
> and
>
> {script style='text/javascript'}
>
> tags ?
>
> easy for designers and readability is also fine.

Hello,

Readability is fine indeed, but what benefits you will have with
{css}
and {script} tags?
You can do the same with standard html notation and with similar
capacity of code.

regards
--
Piotr Kabacinski
a2Fib3Q

[Davide Fiorello]

Hi, it's my first post.

I prefer the 2.x way.

I've tons of templates with space between delimiter and variable.
I'ts a good use to make 'breath' the variable. The code it's more
readable.

Why don't put a setting in the config??

[Mark Rogers]

I've not had chance to experiment with Smarty 3 yet, but is it not
possible to define "{ " and " }" as the Smarty delimiters in Smarty 3?

It would mean that {$x} would no longer be picked up by Smarty but if
you've been consistent and always used { $x } that should fix it?

Whether or not it would be possible to define regex delimiters like {\s*
and \s*} I also have no idea, but something like that might make it
possible to support both forms.

Personally I love the new format:
<style>
.table-content: { color: {$color}; }
</style>